Very Long Instruction Word (VLIW) computer architectures were originally proposed in the 1970s. Early descriptions of VLIW processors include “The VLIW Machine: A Multiprocessor for Compiling Scientific Code,” by Fisher, in IEEE Computer (July, 1984), pages 45–53, and “The Cydra 5 Departmental Supercomputer: Design Philosophies, Decisions and Trade-offs,” by Rau et al., in IEEE Computer (January, 1989), pages 12–35, which are incorporated herein by reference. Recently, a number of major manufacturers, including Intel and Hewlett-Packard, have announced their intention to develop VLIW microprocessors. A brief survey of VLIW principles and developments is presented by Pountain in an article entitled “The Word on VLIW,” published in Byte Magazine (April 1996). This article is available at www.byte.com/art/9604/sec8/art3.htm and is incorporated herein by reference.
FIG. 1 is a block diagram that schematically illustrates a multi-instruction Very Long Instruction Word 20, as is known in the VLIW art. (The terms “word” and “VLIW” are used interchangeably hereinafter.) VLIW architectures group together several single instructions 22 in word 20, and execute them in parallel. Additional bits (not shown in the figure) may be added to the word for other purposes, such as specifying the VLIW format or predicating the execution of single instructions. For a given VLIW architecture, there are strong rules dictating the number, types and ordering of single instructions that may be combined in a word. In the hypothetical example shown in FIG. 1, the rules dictate that the first instruction 22 be a memory instruction, the second a floating point unit instruction, and the third and fourth arithmetic instructions. The format of word 20 is shown here by way of example, and many other VLIW formats are also possible, including different types and numbers of instructions in different orders, and incorporation of additional control bits, as noted above. In addition, the VLIW rules place restrictions on the resources that can be used by instructions in a single word, for example, that no two instructions may use the same target register.
A custom VLIW compiler is responsible for converting source code into multi-instruction words that obey the applicable rules. The off-line compiler relieves both the programmer and the processor of the burden of finding the correct order for executing the instructions. The VLIW processor receives the legally-compiled instruction words and executes the instructions in each word in parallel. It thus can achieve higher processing speed than is possible for comparable single-instruction devices, without the need for special hardware to order the instructions for execution at run time, as is required in parallel, super scalar processors.
Because VLIW architectures have not yet gained wide acceptance, there has been only limited work done on testing and simulation tools for use in VLIW processor design. One of the few published accounts of work in this field is an article by Moreno et al., entitled “Simulation/Evaluation Environment for a VLIW Processor Architecture,” in IBM Journal of Research and Development 41:3 (1997). This article is available at www.research.ibm.com/journal/rd/413/moreno.html, and is incorporated herein by reference. The authors describe an environment comprising an optimizing compiler, which generates instructions in a VLIW assembly language; a translator from VLIW assembly code into IBM PowerPC® assembly code, which emulates the functionality of the VLIW processor for the specific VLIW program; and a cycle timer, invoked by the emulating code, which processes VLIW execution traces as they are generated.
The environment described by Moreno et al. relies on static compilation and translation of instructions prior to simulation, rather than any sort of dynamic instruction generation during simulation. Static test generation is the most common method for functional verification of all sorts of circuit designs. The test engineer (or test generation program) prepares a sequence of instructions, which are expected to give certain results when run by the circuit under test. After the test generation is completed, the test instructions are passed to an architectural simulator program, also known as a behavioral simulator, which models the execution of the instructions by the target hardware. The results of the simulation are compared to the expected results. Any differences are indicative of potential bugs.
Dynamic test program generators are also known in the art of functional verification. They are used mainly for testing designs of single-instruction processors. Although typically more complex to implement than static approaches, dynamic testing enables test instructions to be generated while taking into account the current state of the processor, so that the simulator can run “smarter” tests. For example, U.S. Pat. No. 5,202,889, to Aharon et al., whose disclosure is incorporated herein by reference, describes a dynamic process for the generation of biased, pseudo-random test instruction patterns for the functional verification of hardware designs. The dynamic test generation approach combines instruction generation and simulation in a single process. The test program generator chooses each instruction in sequence, selects the resources the instruction is to use, and initializes the simulated resources as necessary to define the beginning state of the test pattern. Each instruction that is generated is passed immediately to the simulator for execution. The simulator executes the instruction and updates its resources to reflect the appropriate simulation state, according to the semantics of the instructions received from the test program generator. It then returns the results to the test program generator, for use in determining the next instruction to generate. This results enable the test program generator, for example, to create a resource dependency between successive instructions.
Thus, dynamic test program generation provides an efficient, generic means for testing different features of device designs. Although the dynamic approach has been used mainly for functional verification of large-scale microprocessors, such as the PowerPC and Intel x86 families, it can also be adapted to target devices of other kinds. For example, Rubin et al. describe a new dynamic testing methodology for digital signal processors in an article entitled “Fast Construction of Test-Program Generators for Digital Signal Processors,” published in the proceedings of the IEEE International Conference on Acoustics, Speech and Signal Processing—ICASSP'99, vol. 4 (1999), pages 1989–1992, which is incorporated herein by reference. As another example, U.S. Pat. No. 5,592,674, to Gluska et al., whose disclosure is incorporated herein by reference, describes a method for automatic verification of external interrupts based on a dynamic testing approach, which is applicable to pipelined and super scalar microprocessors. Other methods for verification and simulation based on dynamic test program generation are described in U.S. Pat. No. 5,572,666, to Whitman; U.S. Pat. No. 5,729,554, to Weir et al.; U.S. Pat. No. 5,732,247, to Dearth et al.; and U.S. Pat. No. 5,956,478, to Huggins. The disclosures of all of these patents are incorporated herein by reference.
The dynamic testing approach is, in principle, also applicable to VLIW architectures. Dynamic test program generators developed for single-instruction architectures, however, are not suitable for generating VLIW instructions. For one thing, single-instruction devices do not have anything like the strict, general rules imposed on instruction grouping and ordering for VLIW devices. (At most, in a single-instruction device, certain specific instructions must be preceded or succeeded by certain other instructions.) Therefore, single-instruction test generators, as are known in the art, do not have the facilities to deal with rules like these. In addition, VLIW devices have rules governing the legality and semantics of resource selection for a given single instruction that differ fundamentally from those used in single-instruction devices. For example, as noted above, the same target registers typically cannot be used twice in a VLIW. Moreover, the source registers for all of the instructions in the word use the data that existed before the execution of any of the instructions, even when the instructions were generated before the particular data.
Thus, existing dynamic test program generators are not by themselves suitable for use in testing VLIW architectures. It would therefore appear to be necessary to develop new, dedicated dynamic test program generators to serve the special needs of testing VLIW architectures.